A software container is an instance of a user-space running an application within the operating system (OS) of a host device (e.g., a server). Software containers enable operating-system-level virtualization in which the OS kernel allows the existence of multiple isolated software containers.
A software container (or a container) provides an executable environment with a complete filesystem. The filesystem may contain code, runtime, system tools, system libraries, and so on. That is, execution of a software container can be the same regardless of the underlying infrastructure. A Docker is one popular existing platform for creating, migrating, managing, and deploying software containers.
A software container, unlike a virtual machine, does not require or include a separate operating system. Rather, the container relies on the kernel's functionality and uses hardware resources (CPU, memory, I/O, network, etc.) and separate namespaces to isolate the application's view of the operating system. A software container can access the OS kernel's virtualization features either directly or indirectly. For example, Linux kernel can be accessed directly using the libcontainer library or indirectly using the libvirt service.
As demonstrated in FIG. 1, a number of software containers (i.e., the app containers 110-1 through 110-n, hereinafter referred to individually as a container 110, merely for simplicity purposes) can access and share the same OS kernel 120. However, each container 110 can be constrained to only use a defined amount of hardware resources (e.g., CPU, memory, etc.) in the underlying hardware layer 130. Thus, using software containers, hardware resources can be isolated, services can be restricted, and processes can be provisioned to have an almost completely private view of the operating system with their own process ID space, file system structure, and network interfaces.
FIG. 2 illustrates a typical structure of a software container 200. The software container 200 includes a base image 210 and a container layer 220. The base image 210 includes one or more image layers 215-1 through 215-q (hereinafter referred to individually as a layer 215 and collectively as layers 215, merely for simplicity purposes). The layers 215 are read-only layers that represent filesystem differences. That is, the layers 215 are stacked on top of each other to form a base for the root filesystem of the container 200. The layers 215 are read only, and each layer 215 is identified by a randomly generated identifier number of a checksum computed using a hash function. All layers 215 and the base image 210 are collectively referred to as a “container image”.
The base image 210 (and its layers 215) can be shared across different software containers. Thus, only the container layer 220 differentiates between one software container and another. The container layer 220 is a readable and writable layer where all data written to the software container 200 is saved in the container layer 220. When the software container 200 is deleted, the writable container layer 220 is also deleted, and the base image 210 remains unchanged. As such, the software container 200 and other software containers (not shown) can share access to the same base image 210, where each software container has its own data state. In the example demonstrated in FIG. 2, the software container 200 is a Docker container (e.g., compliant with the Docker platform).
The popularity of software containers has been increased due to the easy integration with cloud-computing platforms (e.g., Amazon® Web Services, Google® Cloud Platform, Microsoft® Azure, etc.). On such platforms, service providers can offer operating systems to run services and applications. With that said, the increasing reliance on software containers increases the need for secured execution.
Container images are typically uploaded and stored in image registries that may or may not be managed by an organization. Further, the base images are used across many container images of the organization. Therefore, hackers can take advantage of this property of shared images by including malicious code. Such malicious code may carry any type of malware including, for example, computer viruses, worms, Trojan horses, ransomware, spyware, adware, scareware, and the like. Further, such malicious code may be a source for an ATP attack or a distributed denial of service (DDoS) attack when a software container is executed with an infected or malicious image.
Networking between containers is typically accomplished through software defined networks that use multiple layers of abstraction and translation to send traffic between endpoints. Web applications in such environments are often deployed in random servers and accessed via random IP addresses.
Traditionally, web application firewalls (WAFs) is one solution for protecting web applications in such environments. WAF usually require users to manually define static rules for determining what types of applications run on which endpoints and for inspecting traffic based on such determined types. Most WAFs solutions profile the protected applications and inspect traffic directed to such applications. Traffic data that does not match the profiles would be blocked.
However, traditional WAF solutions cannot operate efficiently in containerized environments because the deployment and execution of applications in such environments change rapidly and unpredictably.
For example, a two-tiered web application requires a web server connected to a database. The web server and database are each deployed in their own separate containers using an orchestration tool. At the time of deployment, the orchestration tool determines what servers in a cluster server is best suited to run each container (e.g., the servers with the most resources available) and automatically deploys the containers without further human interaction. Then, the deployed containers are connected to a software defined network (SDN) that spans the hosts and assigned random IP addresses.
As can be understood from the above example, WAF and other application layer filtering solutions that use static rules are infeasible to protect web applications executed in containers, because such solutions cannot determine what applications are currently executed and where they are executed. Thus, no protections can be applied to them, and how to route traffic to the proper destinations.
It would therefore be therefore advantageous to provide a solution that would overcome the deficiencies noted above.